Talk:Killer App/@comment-25739219-20141121182948/@comment-25737900-20141121184432
While some good points are mentioned in the message above, I disagree with some of them. IDLE is included in the Python standard library so that users are guaranteed to have an editor to write Python programs - not to write programs in a visual block based language. Python 3 assumes by default that the source files are encoded in utf-8; there is no need to specify a different encoding since all human languages can be written using utf-8. In the course of the past 10 years, I have given a fair bit of thought about translating programming environments (I wrote a blog post summarizing some of these thoughts just 2 days ago: http://aroberge.blogspot.ca/2014/11/translating-programming-environment.html). I strongly disagree with the idea of translating Python keywords. Again, to reiterate: IDLE is a tool included with Python to write Python programs. Edit --- I apologize for the tone of my comment as written above. I will provide a bit more context: IDLE is meant to be a readily available editor to write Python code. I am 99.999% confident that the Python maintainers would never accept to support something that runs anything but true Python code. Once a module is accepted to be part of the standard library, a commitment is made to maintain this module in future versions. And the goal here is to have a replacement for the IDLE version that exists currently. Ok... suppose that my confidence does not reflect reality and that the idea of using non-English keywords (and/or a visual language) would be accepted as something to be included in the official Python standard library. So, let's see what happens if we want to run such code. When code is executed, it is tokenized, parsed and "compiled" into Python bytecode which is then executed. This toolchain can not be made to understand different (translated) keywords without being recompiled entirely. You might think "what about if we just add a translation process when code is run within IDLE, doing some string replacements based on user-defined configuration before passing it to the tokenizer?" This *could* perhaps be doable ... However, suppose I write a module A using French keywords and I save it. I then write module B, also using French keywords; this module includes some import statements, importing both modules from the standard library and my module A. So, how is module A going to be treated? .... Well, if you want it to be parsed and translated as well, you have to change the Python modules that deal with the import mechanism: a simple string based replacement will no longer be sufficient since "IDLE" would not be used to run this file directly. So, I no longer can use the Python interpreter. Similarly, if I write module A and I want to use it within the REPL "sub-window" ... well, this REPL can not be the standard one that is included with the Python distribution ... you'll have to rewrite a completely new one, which would meant a new abstract syntax module, a new tokenizer, parser, etc. This would require a gigantic effort. Suppose this is done within this super-IDLE. Great... I'm a French speaker (which is indeed the case!) and I learned (French) Python using French keywords. I'm becoming pretty good at it and read that SublimeText and/or PyCharm are fantastic tools for more advanced programmers. So, I try to use them with my programs .... and it just does not work. There are very few Python keywords (and very few built-in functions that are of much use initially). It is not a great cognitive effort to learn these keywords while learning to program in Python.